تحكم MQTT المباشر

تلميح

التحكم بـ MQTT المباشر مخصص للتحكم الحي. لإرسال الجداول مسبقًا، انظر التحكم المجدول بـ MQTT بدلاً من ذلك.

ستساعدك هذه التوجيهات في تكوين MQTT على Sofar EMS للتحكم عن بُعد ومراقبة التثبيتات الخاصة بالبطاريات والألواح الشمسية.

ما تحتاجه

1. Sofar EMS مع الاتصال بالإنترنت.
2. بيانات اعتماد MQTT: يمكن طلبها عن طريق إرسال بريد إلكتروني إلى support@eniris.be.
3. بيئة تطوير بايثون (أو أي عميل MQTT آخر). تستخدم هذه الإرشادات مثالاً بسيطًا مكتوبًا بلغة بايثون لمساعدتك على البدء في استخدام MQTT وإرسال الأوامر. ننصح باستخدام بايثون لسهولة الاستخدام، لكن يمكن دعم أي عميل MQTT آخر.

معلومات إضافية

MQTT هو بروتوكول اتصال سريع عبر الإنترنت. إنه نظام رسائل نشر/اشتراك، مما يسمح بإنشاء اتصال مباشر بين جهازك وSofar EMS. يتم تصنيف أصولك إلى مجموعات من الألواح الشمسية والبطاريات والسيارات الكهربائية ونظم التدفئة والتكييف.

التكوين الأول (نقطة البداية للمستخدمين الجدد)

لدي Sofar EMS أود إعدادها للتحكم عن بُعد عبر MQTT.

1. تحقق من الشبكة الخاصة بك

تأكد من أن الشبكة الخاصة بك تسمح بحركة مرور شبكة MQTT عبر المنفذ 1883. يمكنك القيام بذلك باستخدام الأمر:

nc -zv mqtt.eniris.be 1883

عندما لا يتوفر هذا الأمر، يمكنك بدلاً من ذلك تنزيل وتنفيذ هذا الكود بلغة بايثون.

عند الشك، استشر مهندس الشبكة الخاص بك أو استخدم مؤقتًا نقطة اتصال 4G/5G من هاتفك عند حدوث أخطاء في الاتصال.

ملاحظة

عندما يكون المنفذ 1883 غير متاح من شبكتك، نقدم بديلاً على المنفذ 80. يمكن تكوين هذا في عميل MQTT الخاص بك في خطوة لاحقة من هذا الدليل.

2. إضافة أجهزتك

تسجيل الدخول إلى واجهة التكليف وتأكد من أن الأجهزة قد أُضيفت إلى Sofar EMS.

3. إضافة إشارة MQTT الخارجية

4. تمكين إشارة MQTT عن بُعد

يجب ترك حقل 'معرف VPP' فارغًا.

يخبر مهلة آلية الاحتياط Sofar EMS بالمدة التي يجب أن تنتظرها للأوامر الجديدة. عندما يتوقف Sofar EMS عن تلقي الأوامر، فإنه يتبنى استراتيجية افتراضية تلقائيًا بعد هذه المهلة.

بعد ذلك، حدد جميع الأجهزة التي ترغب في تضمينها في التحكم عن بُعد عبر MQTT.

5. تمت إضافة الإشارة عن بُعد

لقد تم الآن تنشيط واجهة التحكم عن بُعد عبر MQTT على Sofar EMS.

نحن الآن مستعدون لإرسال بعض الأوامر الأساسية باستخدام مثال بسيط. تخبرك عمود الحالة إذا كانت أي أمر نشط.

نص البرنامج التجريبي بلغة بايثون

يعد نقطة بداية جيدة لاختبار تكامل التطبيق الخاص بك إعداد جديد بمثال بسيط.

يقوم كود الاختبار هذا بعمل بسيط وهو إرسال الأوامر التالية باستمرار:

• البطارية: الشحن عند 5 كيلووات
• الطاقة الشمسية: تعيين القدرة إلى 0 كيلووات

يجيب Sofar EMS باستمرار برسالة 'تغذية راجعة' تحتوي على قيم الطاقة المُلاحظة للشبكة والأصول. هذه الميزة مدرجة أيضًا في هذا المثال.

يرجى تنزيل الملف أدناه في IDE الخاص بك المفضل لبايثون. قم بملء رقمك التسلسلي وبيانات اعتماد MQTT وتنفيذ البرنامج النصي:

عندما يكون كل ما سبق ناجحًا، يمكنك المتابعة بإرسال أنواع أخرى من الأوامر. تم وصف جميع الأوامر في وثائق التحكم عن بُعد عبر MQTT.

وثائق MQTT لإرسال الأوامر

توضح هذه القسم تنسيق رسائل MQTT ومتطلبات الحمولة للتحكم عن بُعد في سياسات الطاقة على الأجهزة ضمن شبكة Sofar EMS.

موضوع MQTT

موضوع MQTT المستخدم لإرسال الأوامر مبني كما يلي:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

حيث يجب استبدال 'controller SN' برقم التسلسل الفعلي لـ Sofar EMS الذي تنوي التحكم فيه.

هيكل الحمولة الخاصة بـ MQTT

يتم إرسال الأوامر كحمولات JSON. تم تصميم هيكل الحمولة لتحديد سياسات إدارة الطاقة المختلفة والنقاط المحددة لمكونات نظام الشبكة الذكية المختلفة. فيما يلي ملخص للحمولة مع أوصاف الحقول التفصيلية:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

وصف الحقول

تلميح

يمكن التحكم في أنواع أجهزة متعددة (مثل البطاريات + الطاقة الشمسية) في نفس الوقت.

• extraTags (كائن):
  • nodeId (سلسلة): معرّف فريد للعقدة ضمن شبكة Sofar EMS. يساوي رقمك التسلسلي، يليه '_site_0' لمعظم أجهزة Sofar EMS.
• time (عدد صحيح): طابع زمني Unix بالثواني يشير إلى الوقت الذي يتم فيه إرسال الرسالة.
• fields (كائن):
  • <Component>_policy (سلسلة): نوع السياسة للمكون. هذا اختياري وإذا لم يتم تحديده، ستعود النظام إلى الإعداد الافتراضي لـ Sofar EMS.
  • <Component>_power_setpoint_w (عائم): نقطة القدرة المطلوبة بالواط للمكون. هذا اختياري وذو صلة فقط إذا تم تحديد سياسة صحيحة.

المكونات والسياسات

معلومات

سيتم دمج الأصول من نفس النوع (مثل بطاريتين) كعنصر واحد. على سبيل المثال، عندما مُركبت بطاريتين سعة 5 كيلووات ساعة، ستُعتبر كواحدة بسعة 10 كيلووات ساعة.

يمكن أن يتضمن كل مكون في كائن fields سياسة ونقطة طاقة. يمكن التحكم في المكونات التالية:

• solar_policy و solar_power_setpoint_w:

  • يتحكم في سياسة توليد الطاقة الشمسية ونقطة القدرة. السياسات المدعومة:
    • نقطة السياسة: تعيين الحد الأقصى للطاقة المنتجة من جميع التركيبات الشمسية المتصلة معًا. يجب تعيين حقل solar_power_setpoint_w على حد إنتاج الطاقة بالواط.
    • سياسة قيود التغذية: إنتاج الطاقة بأقصى طاقة، وفقًا لحدود الشبكة الحالية.
    • سياسة التكلفة: تمكين تقليل تكلفة الأسعار مع يوم سابق (سوق EPEX Spot) على إنتاج الطاقة الشمسية. عندما تأتي أسعار حقن سالبة، نقوم بتقليل الإنتاج للاستهلاك الذاتي. عندما تكون كل من أسعار السحب والحقن سالبة، نقوم بإيقاف جميع التركيبات الشمسية. يتم تجاهل حقل solar_power_setpoint_w.
    • سياسة الإيقاف: تعطيل جميع التفاعلات لجميع الأصول الشمسية. تحذير: الحدود غير محفوظة في هذا الوضع. يتم تجاهل حقل solar_power_setpoint_w.

• storage_policy و storage_power_setpoint_w:

• يتحكم في سياسة نظام تخزين الطاقة ومعدل تفريغ أو شحن الطاقة.

  • نقطة الضبط السياسية: تعيين إجمالي طاقة الشحن (نقطة ضبط إيجابية) أو طاقة التفريغ (نقطة ضبط سلبية) لمجموعة البطاريات. عندما تكون هناك بطاريات متعددة متصلة، يتم تقسيم نقطة الضبط حسب الطاقة المتاحة للشحن/التفريغ لضمان توزيع الضغط بالتساوي على البطاريات. يتم تعيين حقل storage_power_setpoint_w على طاقة البطارية المطلوبة.
  • تكلفة السياسة: تمكّن من تحسين تكلفة سعر اليوم (سوق EPEX الفوري) على البطاريات، من خلال شحنها في الساعات الرخيصة واستخدام الطاقة في الساعات المكلفة. يتم تجاهل حقل storage_power_setpoint_w.
  • سياسة الاستهلاك الذاتي: تمكّن من تنفيذ خوارزمية بسيطة لاستهلاك الطاقة الذاتية على البطاريات. يتم تخزين الإنتاج الزائد من الطاقة الشمسية في البطارية، وعندما تغرب الشمس، يتم سحب الطاقة من البطارية. يتم تجاهل حقل storage_power_setpoint_w.
  • سياسة الإيقاف: تعطيل جميع التفاعلات لجميع أصول البطاريات. تحذير: لا يتم حماية الحدود في هذا الوضع. يتم تجاهل حقل storage_power_setpoint_w.

• heat_pump_policy:

  • يبدّل تشغيل/إيقاف أنظمة مضخات الحرارة. سيتم دائمًا احترام الحد الأدنى والأقصى لأوقات التشغيل.
    • تكلفة السياسة: تمكّن من تحسين تكلفة سعر اليوم (سوق EPEX الفوري) على مضخات الحرارة. تحدد خوارزمية التسعير الديناميكي المحلي أفضل فترات التشغيل.
    • سياسة الاستهلاك الذاتي: تشغيل مضخات الحرارة إذا تم إنتاج طاقة شمسية زائدة.
    • سياسة إيقاف الطاقة: إيقاف مضخات الحرارة.
    • سياسة تشغيل الطاقة: تشغيل مضخات الحرارة.

• switched_load_policy:

  • يبدّل تشغيل/إيقاف الأنظمة التي يتم التحكم فيها بواسطة الريلاي. قد يكون هذا الريلاي المدمج أو ريلايات متصلة بالشبكة.
    • تكلفة السياسة: تمكّن من تحسين تكلفة سعر اليوم (سوق EPEX الفوري) على الريلاي.
    • سياسة الاستهلاك الذاتي: تشغيل الريلاي إذا تم إنتاج طاقة شمسية زائدة.
    • سياسة إيقاف الطاقة
    • سياسة تشغيل الطاقة

• variable_power_load_policy و variable_power_load_power_setpoint_w:

  • يدير سياسة استهلاك الطاقة الكهربائية للمركبات الكهربائية ونقطة الضبط.
    • نقطة الضبط السياسية: تعيين إجمالي طاقة الشحن لمجموعة المركبات الكهربائية. يتم تعيين حقل variable_power_load_power_setpoint_w على طاقة الشحن المطلوبة.
    • تكلفة السياسة: تمكّن من تحسين تكلفة سعر اليوم (سوق EPEX الفوري) على البطاريات، من خلال شحنها خلال الساعات الرخيصة. يتم تجاهل حقل variable_power_load_power_setpoint_w.
    • سياسة الاستهلاك الذاتي: تمكّن من الشحن إذا تم إنتاج طاقة شمسية زائدة. يتم تجاهل حقل variable_power_load_power_setpoint_w.
    • السياسة السلبية: تعطل جميع التفاعلات لجميع أصول المركبات الكهربائية. يتم تجاهل حقل variable_power_load_power_setpoint_w.

• site_policy و site_power_setpoint_w:

  • يدير حدود تصدير الموقع.
    • سياسة التصريح: تعيين حد التصدير للموقع. يتم تعيين حقل site_power_setpoint_w على حد التصدير.
    • سياسة الافتراضي: تعيد ضبط حد الموقع إلى طاقة التصدير الافتراضية، كما هو محدد في تكوين المتحكم.

التحكم في الأجهزة

يمكن أيضًا التحكم في الأجهزة المحددة بدلاً من مجموعات الأجهزة بناءً على أنماطها. الرسالة مهيكلة بنفس الطريقة:

• nodeId_policy و nodeId_power_setpoint_w

عند إرسال أمرين إلى نفس الأصل (مثل أمر محدد لجهاز إلى عاكس الطاقة الشمسية، وأمر لجميع الأجهزة الشمسية)، ستفضل طريقة التحكم الخاصة بالجهاز على التحكم القائم على نوع الجهاز.

سلوك التراجع

لكل مكون، إذا لم يتم تحديد _policy و _power_setpoint_w، سيستخدم النظام تلقائيًا سياسة التراجع المكونة في Sofar EMS. يضمن ذلك عمل كل جهاز أو مجموعة أجهزة بشكل آمن واستمرار عمله حتى في حال عدم تقديم تعليمات محددة.

إذا لم يتم إرسال أي أمر على الإطلاق، بعد 60 ثانية (أو الفترة المحددة)، سيتم إعادة تنشيط السياسات الافتراضية للأصول.

إلغاء الأوامر الحالية والعودة إلى أوضاع التحكم المحلية

يمكن إلغاء أمر نشط عن طريق إرسال رسالة أمر تراجع.

أمر التراجع

سيقوم أمر التراجع بإلغاء الأمر الحالي فوراً وسيتولى Sofar EMS السيطرة على التركيب. تعتمد السياسة المنفذة على ما هو محدد في إعدادات Sofar EMS.

يمكن أيضًا استخدام هذا في الحالات التي يتم فيها استخدام إشارة تحكم ثانوية، مثل جدول زمني، كانقلاب.

أمثلة الرسائل:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "fallback",
    }
}

أمر فارغ

يمكن إرسال أمر فارغ في أي وقت لجمع معلومات الموقع. لن يلغي هذا الأمر الحالي، ولن يكتب فوق الأوامر من إشارات التحكم الثانوية ذات الأولويات الأدنى.

يتم هيكلة الأمر الفارغ على النحو التالي:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {}
}

مثال على الحمولة

فيما يلي مثال على حمولة لتعيين سياسات ونقاط ضبط متنوعة:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

في هذا المثال، تم تعيين الطاقة الشمسية لتوليد ما يصل إلى 5000 واط، وتم تعيين نظام تخزين الطاقة إما للشحن أو التفريغ بمعدل 5000 واط، حسب علامة قيمة نقطة الضبط. إذا تم حذف أي من solar_policy أو storage_policy، ستعود الأجهزة المعنية إلى الإعدادات الافتراضية التي يحددها Sofar EMS.

وثائق MQTT لاستقبال التعليقات

توضح هذه القسم هيكل ومحتوى رسائل التعليقات المرسلة من Sofar EMS عبر MQTT. يتم نشر هذه الرسائل في الموضوع standard1/outbound/remoteControlMetrics/feedback/<Controller SN> بعد معالجة الأمر.

موضوع تعليقات MQTT

هيكل موضوع تعليقات MQTT كما يلي:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

حيث يجب استبدال <Controller SN> برقم تسلسلي لـSofar EMS الذي يرسل التعليقات.

هيكل حمولة تعليقات MQTT

تكون رسائل التعليقات مهيكلة كحمولات JSON. توفر هذه الحمولة تعليقات مفصلة حول حالة النظام بعد تطبيق أوامر نقاط الضبط، مع مراعاة حدود الشبكة/الجهاز. فيما يلي هيكل حمولة التعليقات مع أوصاف حقولها:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Grid Active Power in Watts>,
                "today_imported_energy_Wh": <Grid Imported Energy in Watt-hours>,
                "today_exported_energy_Wh": <Grid Exported Energy in Watt-hours>,
                "import_limit_W": <Grid Import Limit in Watts>,
                "export_limit_W": <Grid Export Limit in Watts>,
            },
            "vpp_id": "<Virtual Power Plant Identifier>",
            "storage": {
                "energy_stored_Wh": <الطاقة المخزنة بالواط ساعة>,
                "energy_capacity_Wh": <السعة الإجمالية للطاقة بالواط ساعة>,
                "mean_soc_perc": <متوسط نسبة حالة الشحن>,
                "active_power_W": <الطاقة الفعالة بالواط>,
                "executed_power_W": <نقطة الطاقة المرسلة إلى الأجهزة بالواط>,
                "executed_policy": <السياسة المنفذة بواسطة المتحكم>,
                "max_charge_power_W": <أقصى طاقة شحن بالواط>,
                "max_discharge_power_W": <أقصى طاقة تفريغ بالواط>,
                "today_charged_Wh": <الطاقة المشحونة اليوم الحالي بالواط ساعة>,
                "today_discharged_Wh": <الطاقة المفرغة اليوم الحالي بالواط ساعة>,
                "nr_devices": <عدد أجهزة التخزين الخاضعة للتحكم المثبتة>
            },
            "solar": {
                "active_power_W": <الطاقة الفعالة الشمسية بالواط>,
                "executed_power_W": <نقطة الطاقة المرسلة إلى الأجهزة بالواط>,
                "executed_policy": <السياسة المنفذة بواسطة المتحكم>,
                "capacity_W": <سعة الطاقة الشمسية بالواط>,
                "today_energy_Wh": <الطاقة المنتجة اليوم بالواط ساعة>,
                "nr_devices": <عدد أجهزة الطاقة الشمسية الخاضعة للتحكم المثبتة>
            },
            "heat_pump": {
                "executed_policy": <السياسة المنفذة بواسطة المتحكم>,
                "operation_modes": <وضعيات تشغيل مضخة الحرارة>,
                "executed_power_W": <نقطة الطاقة المرسلة إلى الأجهزة بالواط>,
                "nr_devices": <عدد أجهزة مضخة الحرارة الخاضعة للتحكم المثبتة>
            },
            "switched_load": {
                "executed_policy": <السياسة المنفذة بواسطة المتحكم>,
                "devices_on": <عدد الأجهزة التي تعمل>,
                "devices_off": <عدد الأجهزة المطفأة>,
                "executed_power_W": <نقطة الطاقة المرسلة إلى الأجهزة بالواط>,
                "nr_devices": <عدد أجهزة الحمل المتحكم فيها المثبتة>  
            },
            "variable_load": {
                "executed_policy": <السياسة المنفذة بواسطة المتحكم>,
                "executed_power_W": <نقطة الطاقة المرسلة إلى الأجهزة بالواط>,
                "active_power_W": <قوة الجهاز بالواط>,
                "ev_requiring_charge": <هل يحتاج EV إلى الشحن>,
                "currentL1_A": <تيار الجهاز على المرحلة 1 بالأمبير>,
                "currentL2_A": <تيار الجهاز على المرحلة 2 بالأمبير>,
                "currentL3_A": <تيار الجهاز على المرحلة 3 بالأمبير>,
                "executed_current_A": <نقطة التيار المرسلة إلى الأجهزة بالأمبير>,
                "today_charged_Wh": <الطاقة المشحونة اليوم بالواط ساعة>,
                "today_discharged_Wh": <الطاقة المفرغة اليوم بالواط ساعة>,
                "total_charged_Wh": <إجمالي الطاقة المشحونة بالواط ساعة>,
                "total_discharged_Wh": <إجمالي الطاقة المفرغة بالواط ساعة>,
                "min_charge_current_A": <أدنى تيار شحن بالأمبير>,
                "max_charge_current_A": <أقصى تيار شحن بالأمبير>,
                "allow_zero_current": <هل يدعم الشاحن التوقف>
            }
        },
        "response_code": <رمز الاستجابة>
    },
    "fields": {},
    "requestTime": "<الطابع الزمني يونكس>",
    "time": "<الطابع الزمني يونكس>",
    "siteNodeId": "<رقم المتحكم>_الموقع_0"
}
            - executed_policy (Str): السياسات التي تم تطبيقها على العناصر القابلة للتحكم،
            - executed_power_W (Float): مجموع إجمالي الطاقة المطلوبة من الأصول، التي يرسلها خوارزم الأفكار لدينا.
            - active_power_W (Float): يمثل الطاقة النشطة الحالية على الشبكة بالواط.
            - ev_requiring_charge (Bool): هل تتطلب السيارة الكهربائية شحنًا. (هل السيارة متصلة).
            - currentL1_A (Float): تيار الجهاز على المرحلة 1 بالأمبير.
            - currentL2_A (Float): تيار الجهاز على المرحلة 2 بالأمبير.
            - currentL3_A (Float): تيار الجهاز على المرحلة 3 بالأمبير.
            - executed_current_A (Float): مجموع إجمالي التيار المطلوب من الأصول، الذي يرسله خوارزم الأفكار لدينا.
            - today_charged_Wh (Float): الطاقة المشحونة في جهاز شاحن السيارة الكهربائية اليوم. ملاحظة: يتم تقديم اليوم بتوقيت UTC.
            - today_discharged_Wh (Float): الطاقة التي تم تفريغها في جهاز شاحن السيارة الكهربائية اليوم. ملاحظة: يتم تقديم اليوم بتوقيت UTC.
            - total_charged_Wh (Float): إجمالي الطاقة المشحونة في جهاز شاحن السيارة الكهربائية.
            - total_discharged_Wh (Float): إجمالي الطاقة التي تم تفريغها في جهاز شاحن السيارة الكهربائية.
            - min_charge_current_A (Float): الحد الأدنى للتيار الذي يمكن شحن السيارة الكهربائية عنده.
            - max_charge_current_A (Float): الحد الأقصى للتيار الذي يمكن شحن السيارة الكهربائية عنده.
            - allow_zero_current (Bool): هل يسمح شاحن السيارة الكهربائية بالتوقف.
        - nodeId (Object):
            - إذا تم تضمين nodeId في الأمر، فإن التعليق سيحتوي على الحالة المقابلة للجهاز.
    - response_code (Int):
        - يشير إلى حالة العملية. عادةً ما يعني response_code 0 النجاح، في حين قد تشير القيم الأخرى إلى أنواع مختلفة من الأخطاء أو معلومات الحالة (يجب تفصيل هذه في مرجع منفصل).

### مثال على الحمولة المدخلة للتعليق
إليك مثال لرسالة تغذية راجعة تتبع أمرًا لتعيين نقاط طاقة مختلفة:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Image 1" maxWidth="450px" />

تظهر هذه التغذية الراجعة الحالة التشغيلية الحالية للنظام بعد تنفيذ نقاط التعيين، مما يدل على التأثيرات على توليد الطاقة الشمسية والتخزين والتفاعل العام مع الشبكة.

## إصدارات MQTT المدعومة والسلوك على المواضيع غير المصرح بها
عند استخدام MQTT، من المهم النظر في الاختلافات في المواصفات بين الإصدارات 3.1 و3.1.1 و5.0، خاصة فيما يتعلق بسلوك الوسيط عندما ينشر العملاء إلى مواضيع غير مصرح بها.

وفقًا لمواصفة MQTT 3.1.1 (انظر مواصفة OASIS MQTT 3.1.1، القسم MQTT-3.3.5-2)، يجب على الوسيط إنهاء الاتصال بمجرد أن يرسل العميل PUBLISH إلى موضوع ليس لديه إذن به. يمكن أن يؤدي هذا السلوك إلى انقطاع غير متوقع للعملاء الذين يحاولون النشر إلى مواضيع خاطئة التكوين أو غير المصرح بها.

في MQTT 3.1، لا توجد هذه المتطلبات. عند نشر عميل إلى موضوع غير مصرح به بموجب هذه النسخة، فإن الوسيط عادةً ما يتجاهل الرسالة (سقوط صامت) دون إنهاء الاتصال. يجعل هذا MQTT 3.1 في بعض الحالات أكثر ملاءمة عندما يكون تحسين متانة الأنظمة ضد أخطاء التكوين أو الأذونات المفقودة مؤقتًا أكثر أهمية من فرض أمان صارم.

على الرغم من أن MQTT 5.0 يقدم القدرة على العمل مع رموز الأسباب (مثل PUBACK مع سبب الرفض)، إلا أن ذلك يتطلب دعمًا من كلا الجانبين، العميل والخادم. وبالتالي، فإن الانتقال إلى MQTT 5.0 يتطلب جهدًا إضافيًا للتنفيذ.

__عواقب تجاهل التوافق:__
إذا اتصل عميل باستخدام MQTT 3.1.1 وحاول نشر رسائل إلى مواضيع غير مصرح بها، فسيقوم الوسيط بإنهاء الجلسة بشكل مفاجئ. قد يؤدي ذلك إلى عدم الاستقرار، وفقدان الاتصال، أو زيادة التحميل بسبب محاولات إعادة الاتصال المتكررة.

__النهج الموصى به:__
لأنظمة حيث قد يحاول العملاء (مؤقتًا) نشر رسائل إلى مواضيع غير مصرح بها، أو حيث لا يتم تنفيذ معالجة الأخطاء بدقة، نوصي باستخدام MQTT 3.1. هذا يضمن اتصالات أكثر استقرارًا ويتجنب الانقطاعات غير المقصودة أثناء التشغيل.